fix(cli): recognise npm >=10.6.0 "npm error" prefix in ENOTEMPTY self-heal#3416
Merged
Apollon77 merged 3 commits intoJul 17, 2026
Merged
Conversation
…-heal
handleNpmNotEmptyError() reads the failed destination path from stderr via
`startsWith('npm ERR! dest')`. Since npm/cli#7414 (npm v10.6.0) npm prints the
log-level name, so the line is `npm error dest ...`. The path is never
extracted, the temp-dir deletion + retry is skipped, and the install aborts
with "Could not handle ENOTEMPTY, because no deletable files were found".
Match both the old and current prefix.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Apollon77
approved these changes
Jul 17, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes npm ENOTEMPTY “self-heal” behavior in the CLI installer by updating stderr parsing to recognize the newer npm (>= 10.6.0) npm error … prefix, so the cleanup logic can correctly locate and delete the blocking temp directory and retry installation.
Changes:
- Update
handleNpmNotEmptyError()to accept bothnpm ERR! dest …andnpm error dest …when extracting the failing destination path. - Add a Work-in-Progress changelog entry documenting the fix.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| packages/cli/src/lib/setup/setupInstall.ts | Extends stderr line matching to also detect npm error dest … so ENOTEMPTY recovery can find the target path on newer npm versions. |
| CHANGELOG.md | Adds a WIP entry describing the npm >= 10.6.0 ENOTEMPTY recovery fix. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On npm >= 10.6.0 the automatic ENOTEMPTY recovery in
handleNpmNotEmptyError()(packages/cli/src/lib/setup/setupInstall.ts) never removes the blocking npm temp directory, so an affected adapter install/upgrade aborts with:even though the directory it needs to delete is right there.
Root cause
The failed destination path is read from
result.stderrvia:Since npm/cli#7414 (npm v10.6.0, 2024-04-25) npm prints the log-level name instead of the old label, so the line is now
npm error dest ….find(...)returnsundefined,errorFilePathshort-circuits toundefined, and the (correct) temp-dir deletion + retry is skipped.Supported Node versions (18/20/22) ship npm from both eras — older npm prints
npm ERR!, npm >= 10.6.0 printsnpm error— so the parser must accept both.Fix
Only the
findpredicate changes; extraction and deletion are untouched, so existing (old-npm) behaviour is unaffected and the previously-missed modern case now matches:Verification
Real-world trigger: js-controller 7.2.2, Node 22.23.1, npm 10.9.8 — npm printed
npm error dest /opt/iobroker/node_modules/.iobroker.govee-smart-b0IGQWNC. Removing that exact directory by hand (which the handler'srmSynctargets and/^\..*-[a-zA-Z0-9]{8}$/matches) unblocked the install, confirming the recovery logic is sound and only the stderr parsing was broken. Path extraction verified against bothnpm error dest …andnpm ERR! dest …;npm run buildpasses.Related field report: #3095 (ENOTEMPTY on update where the automatic recovery silently failed and the reporter was advised to run
iob fixmanually).Follow-up: #3417 addresses the same stale
npm ERR!assumption in the install success check (kept separate as it touches success/failure classification).🤖 Generated with Claude Code